DECUS TRIP REPORT   (12/92)
-----------------
 
 
SESSION:  CONVERTING YOUR VMS APPLICATION TO OPENVMS ON ALPHA AXP
          Presented by:  James A. McGlinchey of Computer Methods
                         Corporation, a consultant dealing in
                         VMS performance management and systems
                         programming.
 
Session Significance:  DEC's sales strategy is to sell "Alpha Ready"
             VAX systems today, since full commercial production
             environments for Alpha will not be ready until 1994.
             This session points out the problems in moving from
             these VAX systems to an Alpha system from a software
             migration perspective.  We can competitively use
             this information where "Alpha Ready" VAX systems are
             being bid.
 
Highlights:  This session was presented by an independent consultant,
             not a DEC employee, and was much more objective (and
             critical) than the run of the mill DECUS presentation
             touting the "company line".   Some highlights follow:
 
             .  There is now a lot of contention in and outside of
                Digital as to what operating system is better, since
                Alpha runs OSF/1, OpenVMS, and WindowsNT.  Expect
                alot of company in-house politics regarding R&D
                resources, sales strategies, etc.
 
             .  One of DEC's primary porting tools, an image translater
                called VEST, is not 100% effective.  Running a program
                through VEST will not qualify it to ship.  This is
                important since alot of 3rd parties claiming to have
                made the port from VAX to Alpha have used this tool and
                have not gone through the necessary verification testing
                required to insure the code actually works on Alpha.
 
             .  Programs run through VEST will run on Alpha only as fast
                as they did on the VAX, best case!  In some cases the
                code may actually run slower than it did before the
                port!  In the December 7, 1992 Digital News and Review
                Lab Report, translated VAX code using VEST ran only
                1/3rd as fast as the same code recompiled on a
                comparably priced AXP workstation.  Furthermore,
                using tools such as pre-processors will only have
                a significant effect on natively compiled Alpha
                code. (8% performance improvement on translated
                images versus 60% performance improvement on
                natively compiled Alpha code).
 
             .  3rd parties also need to be asked by customers whether
                their code has been actually run on Alpha or if it was
                ported using an early emulator.  In some cases, 3rd
                parties may not have even verified their code on an
                Alpha system!
 
             .  Binary translation, using VEST, is only a temporary
                porting measure.  All code should be recompiled if
                it is to be permanently ported to Alpha.  This means
                finding the original source, if its still around,
                and running through it with a fine tooth comb for
                places which could cause synchonization or performance
                problems.  Data alignment and shared data between
                multiple processes can present serious data corruption
                and performance problems for ported code.
 
             .  Migration of a suite of existing applications to Alpha
                should not be under-estimated.  Planning involves several
                stages such as application qualification for
                recompilation or translation, verification and
                interoperability testing, etc.  The planning and
                migration of a company's application suite may take
                8 months or longer.
 
 
High-Level Summary
------------------
 
In summary, in selling against DEC where an Alpha system is being
proposed to an existing DEC customer considering other RISC alternatives
such as PA-RISC, emphasize:
 
.  The migration effort is comparable to migrating to another vendor
   like HP.
 
.  Customers should beware of 3rd party applications that have
   supposedly ported to Alpha.  3rd parties should be asked if the code
   has actually been recompiled or simply translated, whether it was
   ported using an Alpha emulator or on an actual Alpha system, and
   what verification and interoperability test suites the code has
   been run through after the port.
 
.  There are no performance guarantees after the Alpha port.  DEC has
   not released any OLTP benchmark results such as TPC-A.  In addition,
   HP OLTP performance is expected to grow at a faster rate than the
   60% yearly performance growth on Alpha.
 
.  Alpha application availability is very poor.  Beware of 3rd parties
   software vendor commitment claims to Alpha...most of these 3rd
   parties have not yet ported to Alpha.  DEC is only forecasting 500
   applications by the middle of this year and 1000 at year end.  Only
   1/3rd of these are expected to be OSF/1 based, with the rest based
   on OpenVMS.  (Note:  In the February 1993 Unix Review, in an
   article titled "Currents" by the magazine's editor, Andrew Binstock,
   DEC claimed at Alpha system introduction that 50 to 100 vendors had
   products ready to ship.  In the author's discussions with vendors
   committed to Alpha, none has product ready due to the lack of working
   Alpha hardware!).
 
 
-Lou Petrella
 CSO Competitive Program